Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-072

Text File | 1995-12-31 | 60.1 KB | 1,844 lines | [TEXT/R*ch]

Received-Date: Fri, 2 Dec 1994 16:35:35 +0100
From: [e-mail] (Francois Pottier)
Subject: csmp-digest-v3-072
To: [e-mail]
Date: Fri, 2 Dec 1994 16:35:30 +0100 (MET)
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Errors-To: [e-mail]
Reply-To: [e-mail]
X-Sequence: 78

C.S.M.P. Digest             Fri, 02 Dec 94       Volume 3 : Issue 72

Today's Topics:

        ADSP, PPC, Apple Events ? Which to use?
        ASLM, CFM, etc
        Background Only Apps
        Call PostEvent() from a TimeMgr task!
        OSACompile and OSAExecute
        PBCatSearch finder flags?
        Q: SICompletionUPP



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                        Sends you a summary of commands
    subscribe csmp-digest Your Name    Adds you to the mailing list
    signoff csmp-digest            Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail]. Currently no previous volumes of the CSMP
digest are available there.

Also, the digests are available to WAIS users.  To search back issues
with WAIS, use comp.sys.mac.programmer.src. With Mosaic, use
http://www.wais.com/wais-dbs/comp.sys.mac.programmer.html.


-------------------------------------------------------

>From [e-mail] (Graeme Gerrard)
Subject: ADSP, PPC, Apple Events ? Which to use?
Date: Fri, 11 Nov 1994 13:51:40 GMT
Organization: LaTrobe University

I need to send messages to a number
of Macintoshes connected to a host over Localtalk.

The remote Macs will be running the *same program* continuously
and different messages need to be sent to them.
The messages are short, a couple of hundred bytes each
and have to be sent every second or so.
The main criteria is robustness.  The system has to run, with a minimum of
maintenance, for several months.

Which is the best way to go, Apple Events, PPC toolbox, or a combination
of NBP and ADSP?

Advice from anyone with experience in this kind of thing would be
greatly appreciated.

--
Graeme Gerrard                [e-mail]
Music Dept
La Trobe University

+++++++++++++++++++++++++++

>From [e-mail] (Stephen Coy)
Date: Sun, 13 Nov 1994 00:23:28 +1100
Organization: Resolve Software (WA) Pty Ltd

In article <gerrard-1211940051400001@131.172.10.162>,
[e-mail] (Graeme Gerrard) wrote:

> I need to send messages to a number
> of Macintoshes connected to a host over Localtalk.
>
> The remote Macs will be running the *same program* continuously
> and different messages need to be sent to them.
> The messages are short, a couple of hundred bytes each
> and have to be sent every second or so.
> The main criteria is robustness.  The system has to run, with a minimum of
> maintenance, for several months.
>
> Which is the best way to go, Apple Events, PPC toolbox, or a combination
> of NBP and ADSP?
>
> Advice from anyone with experience in this kind of thing would be
> greatly appreciated.
>

Given the frequency of your messages, I would be inclined to build on top
of the PPC toolbox. Combining this with the Threads Manager will allow
your applications to function pseudo-asynchronously, independently of the
Event Manager. The PPC toolbox provides functionality that you would have
to build anyway if you were to build your own stuff on top of ADSP/NBP.

I suspect that the AppleEvent Manager would have trouble with the volume.

--
Steve Coy
Resolve Software (WA) Pty Ltd
4/69 Lynwood Ave
Dee Why NSW 2099
Australia

+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Sun, 13 Nov 1994 11:16:47 +0100
Organization: The Conspiracy

In article <gerrard-1211940051400001@131.172.10.162>,
[e-mail] (Graeme Gerrard) wrote:

>The main criteria is robustness.  The system has to run, with a minimum of
>maintenance, for several months.

>Which is the best way to go, Apple Events, PPC toolbox, or a combination
>of NBP and ADSP?

>Advice from anyone with experience in this kind of thing would be
>greatly appreciated.

For the criteria mentioned, you can use any one of the methods.
NBP/ADSP is the most work, and the easiest on the network.
AppleEvents are much easier to code, but take more bandwidth.
PPC is just in the middle of them. I would use AppleEvents
because they're safe and easy to debug.

What worries me is this:

>I need to send messages to a number
>of Macintoshes connected to a host over Localtalk.
>The messages are short, a couple of hundred bytes each
>and have to be sent every second or so.

LocalTalk has a MAXIMUM data throughput of 25 kB per second.
You have to divide by at least two, probably four, to get a
reliably sustainable data rate without too many collissions.
Two for the collission evasion on an ether media (not Ethernet,
but any CSMD media like LocalTalk), and two more for overhead
in protocols and replies. This gives you 6 kB/sec, or about 12
macs with 500 byte messages.

Max.

Cheers,

                    / h+


--
  Jon W‰tte ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden
 Santa's Reindeer: Fry 1 minced onion, add 1 lb thinly sliced frozen reindeer,
 fry to color, add 1/2 lb mushrooms and 1/2 lb sour cream, simmer 5 mins, add
 soy to taste, salt, pepper. Serve with boiled rice and redcurrant jelly.


+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Mon, 14 Nov 1994 20:32:55 -0800
Organization: Novell, Inc., Walnut Creek/Macintosh Site

In article <gerrard-1211940051400001@131.172.10.162>,
[e-mail] (Graeme Gerrard) wrote:

> I need to send messages to a number
> of Macintoshes connected to a host over Localtalk.
>
> ...The main criteria is robustness....
>
> Which is the best way to go, Apple Events, PPC toolbox, or a combination
> of NBP and ADSP?

Be aware that AppleEvents are based on PPC Toolbox, and PPC Toolbox is
based on ADSP. You probably already knew this, but sometimes it's useful
to hear it out loud. What it means is that no matter which of the three
you pick, your choice will only be as robust as ADSP, but might be less
robust. This might lead you to go with ADSP, if only to reduce the number
of layers involved. However, PPC Toolbox does buy you quicker comm between
processes on the same Mac, and AppleEvents buy you some amount of
simplification, which might end up meaning that the least tested code,
yours, is more robust.

--
 The views expressed here do not necessarily reflect those of my employer.

 "Furthermore, in my mad haste to switch CDs, I dragged the Inside Mac CD-ROM
 icon to the trash and when the Mac ejected it, the tray pushed a glass of
 grape juice off my desk and into my lap. Let that be a lesson to
 development tool vendors: all this would have been avoided with better
 documentation." -- Miguel Cruz <[e-mail]>

+++++++++++++++++++++++++++

>From [e-mail] (Ben Diamand)
Date: Wed, 16 Nov 1994 03:44:59 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

Pete Gontier ([e-mail]) wrote:
: In article <gerrard-1211940051400001@131.172.10.162>,
: [e-mail] (Graeme Gerrard) wrote:

: > I need to send messages to a number
: > of Macintoshes connected to a host over Localtalk.
: >
: > ...The main criteria is robustness....
: >
: > Which is the best way to go, Apple Events, PPC toolbox, or a combination
: > of NBP and ADSP?

: Be aware that AppleEvents are based on PPC Toolbox, and PPC Toolbox is
: based on ADSP. You probably already knew this, but sometimes it's useful
: to hear it out loud. What it means is that no matter which of the three
: you pick, your choice will only be as robust as ADSP, but might be less
: robust. This might lead you to go with ADSP, if only to reduce the number
: of layers involved. However, PPC Toolbox does buy you quicker comm between
: processes on the same Mac, and AppleEvents buy you some amount of
: simplification, which might end up meaning that the least tested code,
: yours, is more robust.

Also be aware that ADSP in built on top of DDP.  Now I know that ddp
is lower level than most want to go, BUT, if you minimum overhead and
still maintain compatability, you might consider DDP as an option.  One
fault of DDP is that it's connection-less, meaning packets can be lost,
so if you can't afford that, ADSP is the way to go...

Ben Diamand
[e-mail]


+++++++++++++++++++++++++++

>From Chris Russo <[e-mail]>
Date: 17 Nov 1994 01:56:47 GMT
Organization: Sonic Systems, Inc.

In article <gerrard-1211940051400001@131.172.10.162> Graeme Gerrard,
[e-mail] writes:
>I need to send messages to a number
>of Macintoshes connected to a host over Localtalk.
>
>The remote Macs will be running the *same program* continuously
>and different messages need to be sent to them.
>The messages are short, a couple of hundred bytes each
>and have to be sent every second or so.
>The main criteria is robustness.  The system has to run, with a minimum of
>maintenance, for several months.
>
>Which is the best way to go, Apple Events, PPC toolbox, or a combination
>of NBP and ADSP?
>
>Advice from anyone with experience in this kind of thing would be
>greatly appreciated.

Go with NBP and ADSP.

Anecdote*:  My office-mate wrote Server Sentry, a remote AppleShare admin,
using AppleEvents - at first.  Unfortunately, he found that AppleEvents sent
to a very busy machine can die without notifying the sender of the error.  He
then took a step back to rely on the PPC toolbox.  Then, you still have to
mess with program linking's dialogs since the PPC toolbox doesn't allow you to
authenticate a user programmatically.  He ended up having to patch
GetNewDialog() to hide Program Linking's password dialog offscreen while he
stuffed the user's name and password into the dialog by posting the events.
Yuck.

Stick with ADSP.  It's a little nitty grittier, but simplicity of a protocol
can have a lot of advantages.  Better to spend a little extra time getting
started with a project because the building blocks are smaller than to start
with a higher level protocol then get stuck mid-project because the protocol
lacks some functionality.  Then you have to hack the hell out of the thing.
See the previous example.

Of course, you might not want to take my word for it.  I like to use DDP
whenever I can. :-)

* Don't blame me for technical inaccuracies in this anecdote.  If necessary,
I'll post the source of these complaints to avoid being flamed. :-)

Thanks,

- ------------------------------------------------------------------------
Chris Russo                      Macintosh Programmer
Sonic Systems, Inc.              [phone] #107
[e-mail]               I'm tired of my signature.

+++++++++++++++++++++++++++

>From [e-mail] (Ben Diamand)
Date: Wed, 16 Nov 1994 03:44:59 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

Pete Gontier ([e-mail]) wrote:
: In article <gerrard-1211940051400001@131.172.10.162>,
: [e-mail] (Graeme Gerrard) wrote:

: > I need to send messages to a number
: > of Macintoshes connected to a host over Localtalk.
: >
: > ...The main criteria is robustness....
: >
: > Which is the best way to go, Apple Events, PPC toolbox, or a combination
: > of NBP and ADSP?

: Be aware that AppleEvents are based on PPC Toolbox, and PPC Toolbox is
: based on ADSP. You probably already knew this, but sometimes it's useful
: to hear it out loud. What it means is that no matter which of the three
: you pick, your choice will only be as robust as ADSP, but might be less
: robust. This might lead you to go with ADSP, if only to reduce the number
: of layers involved. However, PPC Toolbox does buy you quicker comm between
: processes on the same Mac, and AppleEvents buy you some amount of
: simplification, which might end up meaning that the least tested code,
: yours, is more robust.

Also be aware that ADSP in built on top of DDP.  Now I know that ddp
is lower level than most want to go, BUT, if you minimum overhead and
still maintain compatability, you might consider DDP as an option.  One
fault of DDP is that it's connection-less, meaning packets can be lost,
so if you can't afford that, ADSP is the way to go...

Ben Diamand
[e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Ben Diamand)
Date: Wed, 16 Nov 1994 03:44:59 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

Pete Gontier ([e-mail]) wrote:
: In article <gerrard-1211940051400001@131.172.10.162>,
: [e-mail] (Graeme Gerrard) wrote:

: > I need to send messages to a number
: > of Macintoshes connected to a host over Localtalk.
: >
: > ...The main criteria is robustness....
: >
: > Which is the best way to go, Apple Events, PPC toolbox, or a combination
: > of NBP and ADSP?

: Be aware that AppleEvents are based on PPC Toolbox, and PPC Toolbox is
: based on ADSP. You probably already knew this, but sometimes it's useful
: to hear it out loud. What it means is that no matter which of the three
: you pick, your choice will only be as robust as ADSP, but might be less
: robust. This might lead you to go with ADSP, if only to reduce the number
: of layers involved. However, PPC Toolbox does buy you quicker comm between
: processes on the same Mac, and AppleEvents buy you some amount of
: simplification, which might end up meaning that the least tested code,
: yours, is more robust.

Also be aware that ADSP in built on top of DDP.  Now I know that ddp
is lower level than most want to go, BUT, if you minimum overhead and
still maintain compatability, you might consider DDP as an option.  One
fault of DDP is that it's connection-less, meaning packets can be lost,
so if you can't afford that, ADSP is the way to go...

Ben Diamand
[e-mail]


+++++++++++++++++++++++++++

>From Chris Russo <[e-mail]>
Date: 17 Nov 1994 01:56:47 GMT
Organization: Sonic Systems, Inc.

In article <gerrard-1211940051400001@131.172.10.162> Graeme Gerrard,
[e-mail] writes:
>I need to send messages to a number
>of Macintoshes connected to a host over Localtalk.
>
>The remote Macs will be running the *same program* continuously
>and different messages need to be sent to them.
>The messages are short, a couple of hundred bytes each
>and have to be sent every second or so.
>The main criteria is robustness.  The system has to run, with a minimum of
>maintenance, for several months.
>
>Which is the best way to go, Apple Events, PPC toolbox, or a combination
>of NBP and ADSP?
>
>Advice from anyone with experience in this kind of thing would be
>greatly appreciated.

Go with NBP and ADSP.

Anecdote*:  My office-mate wrote Server Sentry, a remote AppleShare admin,
using AppleEvents - at first.  Unfortunately, he found that AppleEvents sent
to a very busy machine can die without notifying the sender of the error.  He
then took a step back to rely on the PPC toolbox.  Then, you still have to
mess with program linking's dialogs since the PPC toolbox doesn't allow you to
authenticate a user programmatically.  He ended up having to patch
GetNewDialog() to hide Program Linking's password dialog offscreen while he
stuffed the user's name and password into the dialog by posting the events.
Yuck.

Stick with ADSP.  It's a little nitty grittier, but simplicity of a protocol
can have a lot of advantages.  Better to spend a little extra time getting
started with a project because the building blocks are smaller than to start
with a higher level protocol then get stuck mid-project because the protocol
lacks some functionality.  Then you have to hack the hell out of the thing.
See the previous example.

Of course, you might not want to take my word for it.  I like to use DDP
whenever I can. :-)

* Don't blame me for technical inaccuracies in this anecdote.  If necessary,
I'll post the source of these complaints to avoid being flamed. :-)

Thanks,

- ------------------------------------------------------------------------
Chris Russo                      Macintosh Programmer
Sonic Systems, Inc.              [phone] #107
[e-mail]               I'm tired of my signature.

+++++++++++++++++++++++++++

>From [e-mail] (Peter Desnoyers)
Date: 18 Nov 94 15:06:14
Organization: Midnight Networks Inc., Waltham MA

In article <[e-mail]> [e-mail] (Jon W{tte) writes:
 >
 >LocalTalk has a MAXIMUM data throughput of 25 kB per second.
 >You have to divide by at least two, probably four, to get a
 >reliably sustainable data rate without too many collissions.
 >Two for the collission evasion on an ether media (not Ethernet,
 >but any CSMD media like LocalTalk), and two more for overhead
 >in protocols and replies. This gives you 6 kB/sec, or about 12
 >macs with 500 byte messages.

You might want to go back and check your math on that one.

Localtalk is actually quite efficient - if you send max size packets
on a loaded net, you will have 400us of inter-frame gap, followed by
an average of 6 RTS transmissions (actually 2e) until one is ACKed
successfully, at 200us each, followed by 20 ms of data. That's an
efficiency of about 93%. (not counting framing and protocol overhead).
Overhead goes up with smaller packets, but you could still get about
80% efficiency with 200-byte packets.

[also, the max data rate on LocalTalk is 230kb/8 = ~29kbyte/sec.]

As far as higher-layer protocol overhead goes, 2x seems like an overly
high estimate, but with the right protocol I'm sure you could make it
even worse than that.

...............................................................................
  Peter Desnoyers  : Midnight Networks Inc. 200 Fifth Avenue Waltham MA 02154
  [e-mail] : Vox 617/890-1001 Fax -0028  The Best in Network Software
--


...............................................................................
  Peter Desnoyers  : Midnight Networks Inc. 200 Fifth Avenue Waltham MA 02154
  [e-mail] : Vox 617/890-1001 Fax -0028  The Best in Network Software


---------------------------

>From [e-mail] (Erik Ackerman)
Subject: ASLM, CFM, etc
Date: Wed, 16 Nov 1994 18:14:57 GMT
Organization: AiC

I am working on a rewrite of an application that would greatly benefit from
being "plugable".  I have been aiming for a code resource spec, but
recently began to consider using ASLM or CFM (need to support 68K).  Does
anyone have any recomendations as to what solution would be best?  Which
will have the greatest longevity and/or support?  etc...

Thanks in advance.

Erik Ackerman

--
[e-mail]

Q: What is the difference between a duck?
A: One of its legs is both the same.

+++++++++++++++++++++++++++

>From [e-mail] (Jason Untulis)
Date: Wed, 16 Nov 1994 20:12:22 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

Erik Ackerman ([e-mail]) wrote:
: I am working on a rewrite of an application that would greatly benefit from
: being "plugable".  I have been aiming for a code resource spec, but
: recently began to consider using ASLM or CFM (need to support 68K).  Does
: anyone have any recomendations as to what solution would be best?  Which
: will have the greatest longevity and/or support?  etc...

>From what I've read, CFM would be your best bet. ASLM is dependent on
cfront C++-style name mangling, whereas CFM should work with any language.
CFM alread exists on PPC, with the beta 68K CFM coming with the OpenDoc
beta which is scheduled for January. I would think that CFM is the
thing that will ge the most support from Apple.
--
- -----
#include <std/disclaimer>           (C) 1994. All rights reserved.
Jason Untulis        untulis@ (netcom.com) (tower.tandem.com)
            [e-mail], [e-mail]
   "You don't want to upset the dinosaurs, do you?" -- CompuServe ad

+++++++++++++++++++++++++++

>From [e-mail] (AFC JLloyd)
Date: 17 Nov 1994 16:20:06 -0500
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]>,
[e-mail] (Erik Ackerman) writes:

>I am working on a rewrite of an application that would greatly benefit
from
>being "plugable".  I have been aiming for a code resource spec, but
>recently began to consider using ASLM or CFM (need to support 68K).  Does
>anyone have any recomendations as to what solution would be best?  Which
>will have the greatest longevity and/or support?  etc...

The answer probably depends upon other requirements.  Do you require C++?
Do you require the ability to develop your "plugs" with several different
compilers?

If you require C++, then you should either use ASLM, which limits the
compilers you can use, or you should use SOM on top of CFM.  If you don't
require C++, then straight CFM is probably your best choice.  If you try
to use C++ on CFM you'll probably be forced to use a single compiler, and
you'll have to worry about the "fragile base class" problem.

If you use SOM, then you'll (in theory) be able to write plugs in multiple
languages/compilers, and the fragile base class problem is almost
completely solved.  SOM language bindings for C and C++ are available now,
and other languages will probably be supported in the future.  Note that
the SOM object model is very similar to Object Pascal's object model, so
you give up some of the features of C++, e.g. no stack-based objects (but
you can have multiple inheritance).  Also note that you can use SOM for
your exported interface, but internally use all the features C++ if you so
choose.

By the way, OpenDoc is being built with SOM/CFM.  One question you should
answer is: can your application be built using OpenDoc?

Jim Lloyd
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Matthew Melmon)
Date: Thu, 17 Nov 1994 20:28:53 GMT
Organization: Cabal Noir:  Glorious Leader

In article <[e-mail]>, [e-mail] (Jason
Untulis) wrote:

> Erik Ackerman ([e-mail]) wrote:
> : I am working on a rewrite of an application that would greatly benefit from
> : being "plugable".  I have been aiming for a code resource spec, but
> : recently began to consider using ASLM or CFM (need to support 68K).  Does
> : anyone have any recomendations as to what solution would be best?  Which
> : will have the greatest longevity and/or support?  etc...
>
> From what I've read, CFM would be your best bet. ASLM is dependent on
> cfront C++-style name mangling, whereas CFM should work with any language.
> CFM alread exists on PPC, with the beta 68K CFM coming with the OpenDoc
> beta which is scheduled for January. I would think that CFM is the
> thing that will ge the most support from Apple.

A really, really, really close-to-beta (RRRCtB) of CFM-68K will be
shipping on ETO 16, in a matter of weeks, now, I suppose.

--
*X*

---------------------------

>From [e-mail] (Christian Taylor)
Subject: Background Only Apps
Date: 7 Nov 1994 16:45:24 -0400
Organization: Nova Scotia Technology Network

Could someone please send me some sample source code of a background only
app in Pascal?  (THINK Pascal actually).  Everytime I try to make a
program background only, the Mac crashes whenever I click in the
Application menu!  And yes, I've read the Tech Note from ftp.apple.com on
BOAs.  Thanks!

Christian

+++++++++++++++++++++++++++

>From [e-mail] (Bob Williams)
Date: 7 Nov 94 19:34:03 -0500
Organization: Enterprise Software

In article <[e-mail]>, [e-mail] (Christian Taylor) writes:
> Could someone please send me some sample source code of a background only
> app in Pascal?  (THINK Pascal actually).  Everytime I try to make a
> program background only, the Mac crashes whenever I click in the
> Application menu!  And yes, I've read the Tech Note from ftp.apple.com on
> BOAs.  Thanks!
>
> Christian

Me too!!! I have the exact same problem. I posted here once before, but noone
answered. I would greatly appreciate it. Thanks!!!

Regards,
Bob
--
+------------------------------------------------------+
|  Robert E. Williams, Jr.                             |
|  Enterprise Software                                 |
|  2006 State Route 380                                |
|  Wilmington, Ohio  45177-9241                        |
|  [phone]                                      |
|                                                      |
|  E-mail: [e-mail]              |
+------------------------------------------------------+
|   Those who are patient in the trivial things in     |
|   life and control themselves will one day have the  |
|   same mastery in great and important things.        |
|      --Hapkido Master Bong Soo Han                   |
+------------------------------------------------------+

+++++++++++++++++++++++++++

>From [e-mail] (Chris Burns)
Date: Tue, 08 Nov 1994 22:23:24 +1200
Organization: AucklandUniversity:ComputerScience:HMU

In article <1994Nov7.193403.33348@miavx1>, [e-mail]
(Bob Williams) wrote:

> In article <[e-mail]>,
[e-mail] (Christian Taylor) writes:

> > Could someone please send me some sample source code of a background only
> > app in Pascal?  (THINK Pascal actually).  Everytime I try to make a
> > program background only, the Mac crashes whenever I click in the
> > Application menu!  And yes, I've read the Tech Note from ftp.apple.com on
> > BOAs.  Thanks!
>
> Me too!!! I have the exact same problem. I posted here once before, but noone
> answered. I would greatly appreciate it. Thanks!!!

THINK Pascal automagically places standard toolbox initialization code at
the beginning of your app. You need to turn this feature off for BOAs by
placing a {$I-} near the top of your main program file. You also need a
_MaxApplZone call (expands heap to fullest), an _InitGraf call (sets up
your app A5 world) and a few _MoreMasters (to preallocate a few master
pointer blocks). Your code goes after this stuff.

{-------------------------}
{$I-}

program blah;

begin
  MaxApplZone;
  InitGraf(@thePort);

  MoreMasters;
  MoreMasters;
  MoreMasters;





end.

{-------------------------}

Chris B
- ---------------------------------------------------------------------
NewZealand:AucklandUniversity:ComputerScience:HyperMediaUnit:ChrisBurns
Internet: [e-mail]
Phone:    [phone] x6194
Fax:      [phone]                         Async, therefore I am.
- ---------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Miika Asunta)
Date: 12 Nov 1994 17:08:43 GMT
Organization: Sibelius Academy, Helsinki

In <1994Nov7.193403.33348@miavx1> [e-mail] (Bob Williams) writes:

>In article <[e-mail]>, [e-mail] (Christian Taylor) writes:
>> Could someone please send me some sample source code of a background only
>> app in Pascal?  (THINK Pascal actually).  Everytime I try to make a
>> program background only, the Mac crashes whenever I click in the
>> Application menu!  And yes, I've read the Tech Note from ftp.apple.com on
>> BOAs.  Thanks!
>>

I'm sorry this in in C, but I believe you can read it anyway.
The projet type must be 'appe' for background application (NOT
'APPL'). In addition, set 'Only background' size option.

Since 'appe' is only background application, don't call usual
toolbox-init routines. You must not use WindowManager, Menu manager
etc.

The following example misses MyQUIT() routine, an apple-event handler,
that you should be able to write yourself.

That application waits quit-apple event forever, and it doesn't eat
system time at all (-:

//----------------------------------------------------------

void HandleEvents(void)
{
WaitNextEvent(highLevelEventMask,&Event,-1L,NULL);
switch(Event.what) {
case kHighLevelEvent:AEProcessAppleEvent(&Event);break;
}}



main()
{
MaxApplZone();
MoreMasters();

AEInstallEventHandler(kCoreEventClass,kAEQuitApplication,&myQUIT,0L,0);

idletime=-1L;

do HandleEvents();
while (!lopetus);
}


//------------------------------------------------------------------------
--
Miika Asunta
[e-mail]            Double Bass Player
tel. [phone]            Macintosh Programmer

+++++++++++++++++++++++++++

>From [e-mail] (Chris Burns)
Date: Sun, 13 Nov 1994 23:07:59 +1200
Organization: AucklandUniversity:ComputerScience:HMU

In article <3a2sqr$[e-mail]>, [e-mail] (Miika Asunta) wrote:

> void HandleEvents(void)
> {
> WaitNextEvent(highLevelEventMask,&Event,-1L,NULL);
> switch(Event.what) {
> case kHighLevelEvent:AEProcessAppleEvent(&Event);break;
> }}
>
>
>
> main()
> {
> MaxApplZone();
> MoreMasters();
>
> AEInstallEventHandler(kCoreEventClass,kAEQuitApplication,&myQUIT,0L,0);
>
> idletime=-1L;
>
> do HandleEvents();
> while (!lopetus);
> }

You really should do an:

InitGraf(&qd.thePort); // Metrowerks C/C++

or

InitGraf(&thePort); // Symantec C++

or

InitGraf(@thePort); // THINK Pascal

after the calls to MaxApplZone() and MoreMasters(). This sets up the A5
world necessary for WNE and context switching.

Chris B
- ---------------------------------------------------------------------
NewZealand:AucklandUniversity:ComputerScience:HyperMediaUnit:ChrisBurns
Internet: [e-mail]
Phone:    [phone] x6194
Fax:      [phone]                         Async, therefore I am.
- ---------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Jason Bobier)
Date: Mon, 14 Nov 1994 09:12:45 -0500
Organization: Prismatix Software


Whoops... couple of problems with this...

In article <3a2sqr$[e-mail]>, [e-mail] (Miika Asunta) wrote:
> I'm sorry this in in C, but I believe you can read it anyway.
> The projet type must be 'appe' for background application (NOT
> 'APPL'). In addition, set 'Only background' size option.

FBA's can have a type of 'APPL' and can be launched at anytime. If the
type is 'appe' they will be put in the extensions folder and launched
automatically at startup if dragged to the system folder.

> main()
> {
> MaxApplZone();
> MoreMasters();

// Add the following
   InitGraf(@qd.thePort);

>
> AEInstallEventHandler(kCoreEventClass,kAEQuitApplication,&myQUIT,0L,0);
>
> idletime=-1L;
>
> do HandleEvents();
> while (!lopetus);
> }

Jason

_____________________________________________________________________
Jason A. Bobier
Prismatix Software

Email: [e-mail]

"Living is easy with eyes closed..."  - The Beatles

+++++++++++++++++++++++++++

>From [e-mail] (Jason Bobier)
Date: Mon, 14 Nov 1994 09:26:44 -0500
Organization: Prismatix Software

In article <[e-mail]>,
[e-mail] (Jason Bobier) wrote:

> Whoops... couple of problems with this...
Whoops... Late night with Macsbug...

> > main()
> > {
> > MaxApplZone();
> > MoreMasters();
>

// What I said
> // Add the following
>    InitGraf(@qd.thePort);

// What I meant
   InitGraf(&qd.thePort);
>
> >
> > AEInstallEventHandler(kCoreEventClass,kAEQuitApplication,&myQUIT,0L,0);
> >
> > idletime=-1L;
> >
> > do HandleEvents();
> > while (!lopetus);
> > }

Sorry,

Jason

_____________________________________________________________________
Jason A. Bobier
Prismatix Software

Email: [e-mail]

"Living is easy with eyes closed..."  - The Beatles

+++++++++++++++++++++++++++

>From here@there (Somone)
Date: 17 Nov 1994 01:10:52 GMT
Organization: Large Fuzzy Room

Here.  The Rez code and the C code to make the simplest possbile FBA.
I took all the comments out so it wouldn't take much space in a posting, if
you need parts of this explained *please* do your research and pull an FBA
sample off summex or somewhere.

/* rez data */
resource 'SIZE' (-1) {
    reserved,
    acceptSuspendResumeEvents,
    reserved,
    canBackground,
    notMultiFinderAware,
    onlyBackground,
    dontGetFrontClicks,
    ignoreChildDiedEvents,
    not32BitCompatible,
    isHighLevelEventAware,
    localAndRemoteHLEvents,
    notStationeryAware,
    dontUseTextEditServices,
    reserved,
    reserved,
    reserved,
    50000,
    50000
};

/* C code */
#include <Events.h>
#include <AppleEvents.h>
#include <QuickDraw.h>
#include <GestaltEqu.h>
#include <SegLoad.h>
struct AEinstalls {
    AEEventClass theClass;
    AEEventID theEvent;
    EventHandlerProcPtr theProc;
};
typedef struct AEinstalls AEinstalls;

Boolean gQuit = false;
EventRecord ERecord;
Boolean gHasAppleEvents;

main()
{
    InitGraf((Ptr)&qd.thePort);
     InitAEStuff();
    while (gQuit == false) {
        WaitNextEvent(highLevelEventMask, &ERecord, 30, 0);
        if (ERecord.what == kHighLevelEvent)
            DoHighLevel(&ERecord);
    }
}

void InitAEStuff(void)
{
    AEinstalls HandlersToInstall[] =  {
         {
            kCoreEventClass, kAEOpenApplication, AEOpenHandler
        },  {
            kCoreEventClass, kAEOpenDocuments, AEOpenDocHandler
        },  {
            kCoreEventClass, kAEQuitApplication, AEQuitHandler
        },  {
            kCoreEventClass, kAEPrintDocuments, AEPrintHandler
        },


    };

    OSErr aevtErr = noErr;
    long aLong = 0;
    Boolean gHasAppleEvents = false;
    gHasAppleEvents = (Gestalt(gestaltAppleEventsAttr, &aLong) == noErr);
    if (gHasAppleEvents) {
        register qq;
        for (qq = 0; qq < ((sizeof(HandlersToInstall) /
sizeof(AEinstalls))); qq++) {
            aevtErr = AEInstallEventHandler(HandlersToInstall[qq].theClass,
HandlersToInstall[qq].theEvent,
                                            HandlersToInstall[qq].theProc,
0, false);
            if (aevtErr) {
                ExitToShell();                              /* just fail,
baby */
            }
        }
    } else {
        ExitToShell();
    }
}

void DoHighLevel(EventRecord *AERecord)
{
    AEProcessAppleEvent(AERecord);

}

pascal OSErr AEOpenHandler(AppleEvent *messagein, AppleEvent *reply, long
refIn)
{
#pragma unused (messagein,reply,refIn)
    return(noErr);
}
pascal OSErr AEOpenDocHandler(AppleEvent *messagein, AppleEvent *reply,
long refIn)
{
#pragma unused (reply, refIn,messagein)
    return(errAEEventNotHandled);
}

pascal OSErr AEPrintHandler(AppleEvent *messagein, AppleEvent *reply, long
refIn)
{
#pragma unused (reply,refIn,messagein)
    return(errAEEventNotHandled);
}

pascal OSErr AEQuitHandler(AppleEvent *messagein, AppleEvent *reply, long
refIn)
{
#pragma unused (messagein,refIn,reply)
    gQuit = true;
    return(noErr);
}

---------------------------

>From [e-mail] (Joakim Grebeno)
Subject: Call PostEvent() from a TimeMgr task!
Date: 9 Nov 1994 15:38:47 GMT
Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden

Hi!
Would it actually be possible to do a PostEvent() from a task
(interrupt) triggered by the TimeManager, or is it forbidden?

I would like to:

1. Setup an action to be executed at a later stage i.e. using
   InsTime() passing it a pointer to a function called A.

2. When the timed action is due to be executed it passes the
   pointer to A to the main event loop using PostEvent() ['app1Evt'].

3. The main event loop receives the event 'app1Evt' and calls
   function A contained in the event.

Would this actually be possible?

Thanks Joakim
--
A: Look! It's a blast-furnace!
B: It's a tree branch!
A: OK! I can see that now!

+++++++++++++++++++++++++++

>From Glenn L. Austin <[e-mail]>
Date: Thu, 10 Nov 1994 17:25:00 GMT
Organization: Eugene FreeNet

In article <39qqe7$[e-mail]> Joakim Grebeno,
[e-mail] writes:
>Would it actually be possible to do a PostEvent() from a task
>(interrupt) triggered by the TimeManager, or is it forbidden?

PostEvent doesn't move memory, so as long as your time manager routine
doesn't move memory (a big no-no), yes, you could post an event.
//
// Glenn L. Austin
// Computer Wizard and Racing Car Driver
// Internet:  [e-mail]
//

+++++++++++++++++++++++++++

>From [e-mail] (Joakim Grebeno)
Date: 11 Nov 1994 08:14:04 GMT
Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden

Glenn L. Austin <[e-mail]> writes:

>In article <39qqe7$[e-mail]> Joakim Grebeno,
>[e-mail] writes:
>>Would it actually be possible to do a PostEvent() from a task
>>(interrupt) triggered by the TimeManager, or is it forbidden?

>PostEvent doesn't move memory, so as long as your time manager routine
>doesn't move memory (a big no-no), yes, you could post an event.

Thanks! That's one problem out of the way! Furthermore I suppose that I
have to setup the my applications A5 world in the task before doing a
PostEvent()?
If this is the case I'm forced to pass two parameters to the TimeManager
task i.e the current A5 *and* the pointer to the function I want to post to
the main event loop. Could this really be done?

Thanks
Joakim

--
A: Look! It's a blast-furnace!
B: It's a tree branch!
A: OK! I can see that now!

+++++++++++++++++++++++++++

>From [e-mail] (Eric Scouten)
Date: Fri, 11 Nov 1994 10:01:38 -0600
Organization: University of Illinois

[follow-ups redirected to comp.sys.mac.programmer.help]

In article <39v94c$[e-mail]>, [e-mail]
(Joakim Grebeno) wrote:

> Thanks! That's one problem out of the way! Furthermore I suppose that I
> have to setup the my applications A5 world in the task before doing a
> PostEvent()?
> If this is the case I'm forced to pass two parameters to the TimeManager
> task i.e the current A5 *and* the pointer to the function I want to post to
> the main event loop. Could this really be done?

Yes, this is very easy to do. Just extend the TMTask record. You can do
something like this:

struct MyTMTask {
   TMTask       tm;
   long         itsA5;
   long         refCon;      // whatever your other parameter was
};


-es

__________________________________________________________________________
Eric Scouten <[e-mail]> * MS Comp Sci '96, Univ of Illinois

IMPORTANT NOTICE TO READERS: The entire physical universe, including this
message, may one day collapse back into an infinitesimally small space.
Should another universe subsequently re-emerge, the existence of this message
cannot be guaranteed.
   -with apologies to Devine & Cohen (Absolute Zero Gravity)

+++++++++++++++++++++++++++

>From [e-mail] (Thomas Reed)
Date: Thu, 10 Nov 1994 10:25:25 -0600
Organization: Washington University

I dunno if calling PostEvent is legal or not in that case.  However, it
sounds like for what you need, a safer method might be to have your TM
task set a certain global flag, which your main event loop constantly
checks for.  When you see the flag set, you call the function.  I use just
this method to draw a picture to the screen every 5 seconds in one of my
programs, and it works quite nicely.

-Thomas

=====================================================
Thomas Reed                     Washington University
[e-mail]           Medical School
[e-mail]            Saint Louis, MO
- ---------------------------------------------------
Clothes make the man.  Naked people have little or no
influence on society.  -- Mark Twain
=====================================================

Opinions posted are not the opinions of Wash. U.

+++++++++++++++++++++++++++

>From [e-mail] (Ben Diamand)
Date: Wed, 16 Nov 1994 04:04:16 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

Joakim Grebeno ([e-mail]) wrote:
: Hi!
: Would it actually be possible to do a PostEvent() from a task
: (interrupt) triggered by the TimeManager, or is it forbidden?

: I would like to:

: 1. Setup an action to be executed at a later stage i.e. using
:    InsTime() passing it a pointer to a function called A.

: 2. When the timed action is due to be executed it passes the
:    pointer to A to the main event loop using PostEvent() ['app1Evt'].

: 3. The main event loop receives the event 'app1Evt' and calls
:    function A contained in the event.

: Would this actually be possible?

While PostEvent doesn't move/purge memory, the MacOS is not necessarily
re-entrant in this area(or almost any area)...In other words, for all
you know, someone else was calling PostEvent whem the timer went off
and was right in the middle of posting an event when you call PostEvent!

This _could_ be really bad...I'd go for the flag/post scheme, where you
flag a variable and then call PostEvent from within your main event loop...

Ben Diamand
[e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Greg Ewing)
Date: 17 Nov 1994 01:13:51 GMT
Organization: University of Canterbury, Christchurch, New Zealand


In article <[e-mail]>, [e-mail] (Ben Diamand) writes:
|> for all
|> you know, someone else was calling PostEvent whem the timer went off
|> and was right in the middle of posting an event when you call PostEvent!

It must surely be possible to post events at interrupt
time - else what do the mouse and keyboard interrupt
handlers do?

I suspect that PostEvent disables interrupts while it is
manipulating the event queue, in which case it would be
safe to call it at interrupt time.

But this is only a *guess* - attempt it at your own
risk!

|> Ben Diamand
|> [e-mail]

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,       | A citizen of NewZealandCorp, a      |
Christchurch, New Zealand       | wholly-owned subsidiary of Japan Inc.|
[e-mail]       +--------------------------------------+

+++++++++++++++++++++++++++

>From [e-mail] (The Weasel)
Date: 17 Nov 1994 19:46:35 GMT
Organization: Computer Science Department, Stanford University.

In article <3aeaof$[e-mail]>,
Greg Ewing <[e-mail]> wrote:
>In article <[e-mail]>, [e-mail] (Ben Diamand) writes:
>|> for all
>|> you know, someone else was calling PostEvent whem the timer went off
>|> and was right in the middle of posting an event when you call PostEvent!
>
>It must surely be possible to post events at interrupt
>time - else what do the mouse and keyboard interrupt
>handlers do?

It is possible to do. Check out PPostEvent. What you get back is the
eventqueue element, dequeue and enqueue turn off interrupts when
playing with the queues. I'm pretty sure that PostEvent is just doing
the same thing.

However, consider what event queue you are going to be slamming this
event into. I sort of missed the start of this discussion so I'm not
sure why you are putting the events in the queue, but you really need
to check to make sure which app is frontmost at the time as it is that
apps eventqueue that is going to be mucked with.

Peter




+++++++++++++++++++++++++++

>From [e-mail] (Ben Diamand)
Date: Wed, 16 Nov 1994 04:04:16 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

Joakim Grebeno ([e-mail]) wrote:
: Hi!
: Would it actually be possible to do a PostEvent() from a task
: (interrupt) triggered by the TimeManager, or is it forbidden?

: I would like to:

: 1. Setup an action to be executed at a later stage i.e. using
:    InsTime() passing it a pointer to a function called A.

: 2. When the timed action is due to be executed it passes the
:    pointer to A to the main event loop using PostEvent() ['app1Evt'].

: 3. The main event loop receives the event 'app1Evt' and calls
:    function A contained in the event.

: Would this actually be possible?

While PostEvent doesn't move/purge memory, the MacOS is not necessarily
re-entrant in this area(or almost any area)...In other words, for all
you know, someone else was calling PostEvent whem the timer went off
and was right in the middle of posting an event when you call PostEvent!

This _could_ be really bad...I'd go for the flag/post scheme, where you
flag a variable and then call PostEvent from within your main event loop...

Ben Diamand
[e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Ben Diamand)
Date: Wed, 16 Nov 1994 04:04:16 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

Joakim Grebeno ([e-mail]) wrote:
: Hi!
: Would it actually be possible to do a PostEvent() from a task
: (interrupt) triggered by the TimeManager, or is it forbidden?

: I would like to:

: 1. Setup an action to be executed at a later stage i.e. using
:    InsTime() passing it a pointer to a function called A.

: 2. When the timed action is due to be executed it passes the
:    pointer to A to the main event loop using PostEvent() ['app1Evt'].

: 3. The main event loop receives the event 'app1Evt' and calls
:    function A contained in the event.

: Would this actually be possible?

While PostEvent doesn't move/purge memory, the MacOS is not necessarily
re-entrant in this area(or almost any area)...In other words, for all
you know, someone else was calling PostEvent whem the timer went off
and was right in the middle of posting an event when you call PostEvent!

This _could_ be really bad...I'd go for the flag/post scheme, where you
flag a variable and then call PostEvent from within your main event loop...

Ben Diamand
[e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Greg Ewing)
Date: 17 Nov 1994 01:13:51 GMT
Organization: University of Canterbury, Christchurch, New Zealand


In article <[e-mail]>, [e-mail] (Ben Diamand) writes:
|> for all
|> you know, someone else was calling PostEvent whem the timer went off
|> and was right in the middle of posting an event when you call PostEvent!

It must surely be possible to post events at interrupt
time - else what do the mouse and keyboard interrupt
handlers do?

I suspect that PostEvent disables interrupts while it is
manipulating the event queue, in which case it would be
safe to call it at interrupt time.

But this is only a *guess* - attempt it at your own
risk!

|> Ben Diamand
|> [e-mail]

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,       | A citizen of NewZealandCorp, a      |
Christchurch, New Zealand       | wholly-owned subsidiary of Japan Inc.|
[e-mail]       +--------------------------------------+

+++++++++++++++++++++++++++

>From [e-mail] (The Weasel)
Date: 17 Nov 1994 19:46:35 GMT
Organization: Computer Science Department, Stanford University.

In article <3aeaof$[e-mail]>,
Greg Ewing <[e-mail]> wrote:
>In article <[e-mail]>, [e-mail] (Ben Diamand) writes:
>|> for all
>|> you know, someone else was calling PostEvent whem the timer went off
>|> and was right in the middle of posting an event when you call PostEvent!
>
>It must surely be possible to post events at interrupt
>time - else what do the mouse and keyboard interrupt
>handlers do?

It is possible to do. Check out PPostEvent. What you get back is the
eventqueue element, dequeue and enqueue turn off interrupts when
playing with the queues. I'm pretty sure that PostEvent is just doing
the same thing.

However, consider what event queue you are going to be slamming this
event into. I sort of missed the start of this discussion so I'm not
sure why you are putting the events in the queue, but you really need
to check to make sure which app is frontmost at the time as it is that
apps eventqueue that is going to be mucked with.

Peter




+++++++++++++++++++++++++++

>From [e-mail] (Fabrizio Oddone)
Date: Thu, 17 Nov 1994 15:42:41 +0100
Organization: Politecnico di Torino - Italy

In article <[e-mail]>, [e-mail] (Ben
Diamand) wrote:

> Joakim Grebeno ([e-mail]) wrote:
> : I would like to:
>
> : 1. Setup an action to be executed at a later stage i.e. using
> :    InsTime() passing it a pointer to a function called A.
>
> : 2. When the timed action is due to be executed it passes the
> :    pointer to A to the main event loop using PostEvent() ['app1Evt'].
>
> : 3. The main event loop receives the event 'app1Evt' and calls
> :    function A contained in the event.

Also, PostEvent() posts the event to the frontmost application, not
necessarily to your app, because there is a single event queue for all the
running apps.

So forget the appXEvt stuff and take a look at the Notification Manager...

--
Fabrizio Oddone
[e-mail]

---------------------------

>From Travis Peckham <[e-mail]>
Subject: OSACompile and OSAExecute
Date: Thu, 17 Nov 1994 17:01:45 GMT
Organization: EMBA Computer Facility, University of Vermont

Hi All,

I was reading the comp.sys.mac.programmer FAQ (trying to get up to
speed on AppleEvents and AppleScript)

I found this:

>5.2) Q:Can I compile and run scripts from my application?

>A: Yes, this is very simple. There are toolbox calls for reading
>scripts, compiling scripts and executing scripts. (OSACompile,
>OSAExecute)...

Does anyone know of some example source code which uses these calls
to compile and execute an AppleScript? I'd be greatful.

Thanks!

Travis

+++++++++++++++++++++++++++

>From [e-mail] (Jeremy Roschelle)
Date: Fri, 18 Nov 1994 09:42:05 -0800
Organization: SimCalc Project

In article <[e-mail]>, Travis Peckham
<[e-mail]> wrote:

> Does anyone know of some example source code which uses these calls
> to compile and execute an AppleScript? I'd be greatful.
>

here are two snippets (CodeWarrior C++) that should get you started:

OSErr
SCScriptEditor::CompileScript()
{
   OSErr err;
   AEDesc   scriptText = {typeChar,nil};

   // get the text we want to compile
   scriptText.dataHandle = mTextEdit->GetTextHandle();
   err = ::OSACompile(GetScriptingComponent(),
                  &scriptText,
                  kOSAModeNull,
                  &mScriptID);
   mCompiledOK = (err == noErr);
   return err;
}

// this executes a script that was previously loaded (with the resulting ID)
void
ExecuteScript(ComponentInstance inScriptingComponent, OSAID inScriptID)
{
   OSAID       resultID;


OSAExecute(inScriptingComponent,inScriptID,kOSANullScript,kOSAModeNull,&resultID);
   OSADispose(inScriptingComponent,resultID);
}

The first snippet stores the script ID in the member variable mScriptID.
You would pass this ID to the Execute function.

// this will get you a scripting component:

   scriptingComponent = OpenDefaultComponent(kOSAComponentType,'scpt');

good luck,

 Jeremy Roschelle
[-------*--------] SimCalc Project
[------*-*-------] 4104 24th Street #344
[-------*--------] San Francisco CA 94114

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Fri, 18 Nov 1994 22:02:16 GMT
Organization: Apple Computer

Travis Peckham, [e-mail] writes:
> Does anyone know of some example source code which uses these calls
> to compile and execute an AppleScript? I'd be greatful.

There's a good article by Paul Smith in a recent issue of 'develop' (17?)
that illustrates this and much more. I don't know the exact issue number
offhand, but each one includes all the back issues on CD-ROM so you can find
it if you get the latest issue.

--Jens Alfke                           [e-mail]
                   "A man, a plan, a yam, a can of Spam ... Bananama!"

---------------------------

>From [e-mail] ()
Subject: PBCatSearch finder flags?
Date: 8 Nov 1994 21:12:16 GMT
Organization: University of Pennsylvania

Hi,
    I am trying to use PBCatSearch to search for files
and EXCLUDE alias files.  The search is already working with
the ioNamePtr and ioFlAttrib flags and I would like to add
whatever it takes to make the search exclude aliases.

    If a file is an alias, then ioFlFndrInfo.fdFlags will
have bit 15 set (0x8000).  Ok, well, in the CInfoPBRec search1
do I set ioFlFndrInfo.fdFlags = 0x0FFF??? (I don't care what the
other 14 bits are) and then set search2 to 0xF000?

    (Search2 is "the mask").  Basically I don't know how
to set the target and mask to include files with bit 15 == 0.
Can some kind soul offer a solution?

THanks!
.


+++++++++++++++++++++++++++

>From [e-mail] (Jump Long)
Date: 17 Nov 1994 03:10:07 -0500
Organization: America Online, Inc. (1-800-827-6364)

In article <39opjg$[e-mail]>, [e-mail] ()
writes:

>Basically I don't know how to set the target and mask to include files
>with bit 15 == 0. Can some kind soul offer a solution?

This will do it for you.

/* find files with alias bit clear */
searchInfo1.hFileInfo.ioFlFndrInfo.fdFlags = 0x0000; /* match when alias
bit is clear */
searchInfo2.hFileInfo.ioFlFndrInfo.fdFlags = 0x8000; /* we're interested
only in the alias bit */

Make sure you clear out the rest of the finder info record in both
searchInfo1 and searchInfo2, and set the fsSBFlFndrInfo search bit.

- Jim Luther


---------------------------

>From [e-mail] (G. Gavazzi)
Subject: Q: SICompletionUPP
Date: 16 Nov 1994 01:30:09 GMT
Organization: University of Cambridge, England

hi,
I am trying to make an asynchronous sound recording (to memory)
and I cannot figure out how to pass the address of my completionRoutine
(and interruptRoutine as well). My program keeps on crashing when
it calls SPBRecord(myinParamPtr,TRUE) since I put in myinParamPtr
the routines addresses.
I use:
SICompletionUPP                mycompletionRoutine(SPBPtr);
SIInterruptUPP                myinterruptRoutine(void);
main(){
SICompletionUPP                mycompletionRoutine(SPBPtr);
SIInterruptUPP                myinterruptRoutine(void);
...
myinParam.completionRoutine = (SICompletionUPP)mycompletionRoutine;
myinParam.interruptRoutine = (SIInterruptUPP)myinterruptRoutine;

}
SICompletionUPP    mycompletionRoutine(SPBPtr inParamPtr)
{
operations on a buffer whose pointer is passed in myinParamPtr->userLong
no return value
}
SIInterruptUPP                myinterruptRoutine(void){}
I don't need to do anything when the input device is full, I could indeed
put myinParam.interruptRoutine = 0; above.

If I put both routines fields in myinParam = 0 my program does not
crash, it simply does not know when it's buffer is full of data.
Can anybody point me to the (C please) solution? (yes, I am going
to buy NIM on CD if it is affordable).
Thank you,
Giuliano Gavazzi

+++++++++++++++++++++++++++

>From [e-mail] (Chris Burns)
Date: Thu, 17 Nov 1994 00:40:45 +1200
Organization: AucklandUniversity:ComputerScience:HMU

In article <3abnb1$[e-mail]>, [e-mail] (G.
Gavazzi) wrote:

> I am trying to make an asynchronous sound recording (to memory)
> and I cannot figure out how to pass the address of my completionRoutine
> (and interruptRoutine as well). My program keeps on crashing when
> it calls SPBRecord(myinParamPtr,TRUE) since I put in myinParamPtr
> the routines addresses.
> I use:
> SICompletionUPP                         mycompletionRoutine(SPBPtr);
> SIInterruptUPP                          myinterruptRoutine(void);
> main(){
> SICompletionUPP                         mycompletionRoutine(SPBPtr);
> SIInterruptUPP                          myinterruptRoutine(void);
> ...
> myinParam.completionRoutine = (SICompletionUPP)mycompletionRoutine;
> myinParam.interruptRoutine = (SIInterruptUPP)myinterruptRoutine;
>
> }
> SICompletionUPP mycompletionRoutine(SPBPtr inParamPtr)
> {
> operations on a buffer whose pointer is passed in myinParamPtr->userLong
> no return value
> }
> SIInterruptUPP                          myinterruptRoutine(void){}
> I don't need to do anything when the input device is full, I could indeed
> put myinParam.interruptRoutine = 0; above.
>
> If I put both routines fields in myinParam = 0 my program does not
> crash, it simply does not know when it's buffer is full of data.




Here's some code I whipped up the other day to do almost exactly this:
The    #pragma parameter    bit was necessary to tell the 68K compiler
where the parameters are stashed on entry in 68K mode.

///////////////////////////////////////////////////////////////////////////////
// Chris Burns 1994
///////////////////////////////////////////////////////////////////////////////

#include <SoundInput.h>

static Boolean FailOSErr(OSErr ErrNum,Str255 ErrMsgStr);
static pascal void MyInterruptProc (SPBPtr PB,Ptr DataBuffer,short
PeakAmplitude,long SampleSize);

///////////////////////////////////////////////////////////////////////////////

static Boolean FailOSErr(OSErr ErrNum,Str255 ErrMsgStr)
{
    if (ErrNum != noErr)
    {
    Str255          ErrStr;
    short           ErrMsgBytes;
    short           Extra;

        NumToString(ErrNum,ErrStr);

        ErrMsgBytes = ErrMsgStr[0];
        Extra = 0;
        if ((ErrMsgBytes + 1 + ErrStr[0] + 1) > 255)
        {
            ErrMsgBytes = 255 - (2 + ErrStr[0] + 1);
            ErrStr[1 + ErrStr[0] + 1] = 'ä';
            Extra = 1;
        }

        BlockMove(&ErrStr[1],&ErrStr[1 + ErrMsgBytes + Extra + 1],ErrStr[0]);
        BlockMove(&ErrMsgStr[1],&ErrStr[1],ErrMsgBytes);

        ErrStr[ErrMsgBytes + 1 + Extra] = '[';
        ErrStr[ErrMsgBytes + Extra + 1 + ErrStr[0] + 1] = ']';
        ErrStr[0] = ErrMsgBytes + Extra + 1 + ErrStr[0] + 1;

        DebugStr(ErrStr);
        return(true);
    }
    return(false);
}

///////////////////////////////////////////////////////////////////////////////

#if !USESROUTINEDESCRIPTORS
#pragma parameter MyInterruptProc(__A0,__A1,__D0,__D1)
#endif

static pascal void MyInterruptProc (SPBPtr PB,Ptr DataBuffer,short
PeakAmplitude,long SampleSize)
{
#if !USESROUTINEDESCRIPTORS
long    SavedA5 = SetA5((*PB).userLong);
#endif






#if !USESROUTINEDESCRIPTORS
    SetA5(SavedA5);
#endif
}

///////////////////////////////////////////////////////////////////////////////

void main (void)
{
OSErr               Err;
long                SIRefNum;
UniversalProcPtr    MyInterruptProcUPP = NewSIInterruptProc(MyInterruptProc);
SPB                 PB;
Boolean             Recording;

    Err = SPBOpenDevice("\p",siWritePermission,&SIRefNum);
    if (FailOSErr(Err,"\p FAILED"))
    {
    }

// Set up recording parameters (rate, sample size, stereo etc) here

    PB.inRefNum = SIRefNum;
    PB.bufferPtr = nil;
    PB.completionRoutine = nil;
    PB.interruptRoutine = MyInterruptProcUPP;

#if !USESROUTINEDESCRIPTORS
    PB.userLong = SetCurrentA5();
#endif

    Err = SPBRecord((SPBPtr)&PB,true);
    if (FailOSErr(Err,"\p FAILED"))
    {
    }

    Recording = true;

    while (Recording)
    {
        Recording = !Button();
    }

    Err = SPBStopRecording(SIRefNum);
    if (FailOSErr(Err,"\p FAILED"))
    {
    }

    Err = SPBCloseDevice(SIRefNum);
    if (FailOSErr(Err,"\p FAILED"))
    {
    }

#if USESROUTINEDESCRIPTORS
    DisposeRoutineDescriptor(MyInterruptProcUPP);
#endif
}

///////////////////////////////////////////////////////////////////////////////

Chris B
- ---------------------------------------------------------------------
NewZealand:AucklandUniversity:ComputerScience:HyperMediaUnit:ChrisBurns
Internet: [e-mail]
Phone:    [phone] x6194
Fax:      [phone]                         Async, therefore I am.
- ---------------------------------------------------------------------

---------------------------

End of C.S.M.P. Digest
**********************